昨天結尾我寫了一句話:我想把「去問人」那一段,變成可以被問第二次。

那麼下一個問題就來了:

被問什麼?

這聽起來像廢話,但它其實是這整個專案唯一真正難的地方。因為只要這一步沒想清楚,你做出來的東西會是一個「什麼都能回答」的玩具——而「什麼都能回答」的另一個講法,是沒有任何一個答案可以被驗收。

所以在寫任何一行程式之前,我先寫了一張表。

那張表

十一個問題。這張表後來就是這個專案的驗收條件——如果它答不出這十一題,那它做得再炫都沒有用。

下面我逐組講,因為每一條背後都是踩過的坑。

PM 那一組:最容易消失的是「否決」

前兩條(目前狀況、先前歷史)很好懂,不解釋。

真正的重點是第三條:為什麼當初決定不做其他擴充。

這是整張表裡我最堅持的一條,因為被否決的事情不會留下任何痕跡。

你想想:一件事只要做了,它就會留下一整條軌跡——卡片、PR、commit、測試紀錄、部署紀錄。但一件事被決定「先不做」,它留下什麼?

什麼都沒有。可能只有某次會議裡的一句「這個先不做」,和一個沒有人記得的理由。

於是六個月後,有人提出同一個想法,團隊再討論一次、再否決一次(如果運氣好),或是這次做了——而當初否決它的那個理由,沒有人記得,可能它到現在還成立。

「我們為什麼沒做 X」是知識庫最有價值、也最難蒐集的一種答案。

第四條(誰做了什麼決定、下一步何時進行)是同一件事的另一面:決定本身是知識,做決定的人和時間也是知識。當你需要回頭改一個決定,你得知道要去找誰。

但這一組其實不是為 PM 寫的

講一件事你可能會覺得不可思議:我們團隊最近才有一個正式的 PM 職位。

在那之前,誰接這個專案的相關功能,誰就是 RD 兼 PM。

這樣運作起來其實沒什麼問題,甚至很有效率——因為大家都知道規則:某某人對這塊比較熟,有問題就問他,要做新功能就找他。

問題只有一個。

只要那個人不在了——離職、調崗、換專案——就會出現資訊斷層。

不是「文件會過期」那種斷層,是整塊知識瞬間歸零。因為它從來沒有離開過那顆腦袋。

而且理論上不該這樣。理論上 RD 做完之後會把資料整理好、上傳、留紀錄。實際上是:

• 紀錄分散在不同平台——一部分在看板、一部分在專案管理系統、一部分在聊天視窗、一部分在 PR 描述裡
• 後續開發速度太快,來不及記錄

所以這張表的 PM 那一組,表面上是為 PM 寫的,實際上是為另一件事寫的:

為了那個人有一天不在了。

QA 那一組:每一條都是我自己的痛

這一組是我自己寫的,所以最狠。

「這張卡的測試範圍」 —— 就是昨天卡 B 那 22 個項目的問題。範圍不是「卡片上寫了幾項」,是「這次改動真的會碰到哪裡」。這兩件事經常差很多。

「過往相關的卡遇過什麼問題、要不要納入回歸」 —— 這是最典型的「知識在人腦裡」的例子。同一塊功能三個月前踩過的坑,新來的人不會知道,而且那個坑通常不在卡片上,是在某則留言的第七段。

「可能跟哪些卡衝突」 —— 這一條是我被咬最多次的。

我們太常發生早上一張 A 卡、下午再一張 B 卡,兩張改同一個畫面。(這個敘述有點誇張,但只有一點點。)

而兩張卡之間的關係,永遠是有交集也有差集:

• 交集的部分,要看先後順序。後改的會蓋掉先改的,所以「哪個是現在的行為」取決於誰先誰後——這件事光看兩張卡本身是看不出來的。
• 差集的部分,要做回歸測試。B 卡動到的地方,可能把 A 卡已經測過的東西弄壞。

然後是真正的代價:

如果你測完 A,才發現有一張 B,那就是一場災難——整個測試過程要再來一次。

不是補測 B 就好,是重來。因為你在 A 上得到的每一個 PASS,都是在「B 還沒進來」的狀態下拿到的,現在全部失效。

所以這一題不是「知道有沒有衝突」而已,它是在你開始測之前就必須知道。晚一天知道,成本就是你已經花掉的所有時間。

要回答它,你得同時知道兩張卡各自改了什麼、誰先誰後——而它們可能分屬不同河道、不同負責人、不同時期。

「是否需要等姊妹卡一起測」 —— 這條最實務。一張卡的功能依賴另一張卡先上線,你先測只會得到一個假的 FAIL,然後浪費所有人半天。

你會發現這四條有個共同點:沒有一條可以靠讀那一張卡本身回答。

RD 那一組:最危險的那一條

RD 的前兩條(影響範圍、要小心哪些段落)性質跟 QA 接近,都是「這件事會波及到哪」。

但第三條不一樣:推薦的修改方式。

這一條我加的時候猶豫過,而且我現在還是覺得它是這張表裡最危險的一條。

前面十條問的都是事實:發生過什麼、決定過什麼、改過哪裡。事實是可以被查證的——講錯了,去翻卡、翻 code 就抓得到。

但「推薦的修改方式」問的是建議。而建議沒有辦法被查證,只能被判斷。

Day 1 那段假規則之所以騙得過我,就是因為我把一段「看起來很專業的建議」當成事實在用。

所以這一條我在心裡是放了但標黃的:它可以出現,但它必須長得跟前面十條明顯不一樣——前面十條要附出處,這一條要附「這是推論」。

(這件事後來變成整個架構的一條線,Phase 3 會講。)

把這張表套到昨天那張卡上

昨天的卡 B——22 個項目、驗收標準第一條是「待確認」的那張。如果知識庫已經存在,三種人會問它什麼?

• PM 會問: 這 22 項裡,哪幾項還卡在「需要產品決策」?是誰要決定?
• QA 會問: 這張卡改到的東西,跟前一張卡是同一塊嗎?要不要回歸?
• RD 會問: 這 22 項裡有哪幾項其實動到同一個檔案,可以一起做?

三個人看著同一張卡,想知道的是三件完全不同的事。

而卡片只有一份。

這就是為什麼答案不能是「把卡片寫得更好」。 不管你把那張卡寫得多完整,它都只能有一種寫法、一種詳細程度、一種預設讀者。你沒辦法用一份靜態文件同時服務三種提問方式——除非它可以被問。

還有第四種人:新人

這個專案最初的名字其實是 onboarding 知識庫,第一個假想使用者是新人。

但我後來發現,新人的問題幾乎完全是上面三組的子集。新人要問的不是別的問題,是同樣的問題。

差別只有一個,而且很致命:

新人不知道自己該問什麼。

PM 知道要問「為什麼不做」,因為他被這個坑咬過。QA 知道要問「要不要等姊妹卡」,因為他浪費過半天。新人什麼都不知道,所以他會問出一個很大很模糊的問題,然後照單全收你給他的答案。

這也是為什麼這個系列的核心是「怎麼知道它答錯了」,而不是「怎麼讓它答得出來」。

一個會唬爛的知識庫,對我來說是麻煩;對一個新人來說,是他對這間公司的第一印象,而且他沒有能力分辨。

寫規格,比寫程式重要

這件事我想單獨講,因為它是 QA 的職業病,而我覺得它在 AI 專案裡特別值錢。

QA 的思考順序天生是反的:先問「怎樣算做完」,再問「怎麼做」。

如果我跳過這張表直接開工,我知道我會做出什麼——一個「能回答關於專案的問題」的東西。然後呢?我怎麼知道它好不好?我會去問它幾個我已經知道答案的問題,它答對了,我覺得很棒。

那不是驗收,那是表演。

有了這十一題,情況完全不同:我可以拿一張真實的卡,逐題問它,然後拿它的答案去對照卡片、對照程式碼、對照當初的會議紀錄。答錯了看得出來,而且看得出來是錯在哪一類。

這也是為什麼我敢在這個系列裡寫「我抓到 8 處錯」——因為在寫第一行程式之前,我就先決定好了什麼叫錯。

最後:這張表不是憑空設計的

我想特別講一下這十一題的來源,因為這決定了它值不值得信。

它不是我坐下來腦力激盪出來的「使用者需求」。它是兩件已經發生過的事的殘骸:

• PM 那一組,來自我們團隊直到最近才有正式 PM 這件事。在那之前知識綁在「誰比較熟」身上,而那個綁法只要一個人離開就整塊歸零。
• QA 那一組,來自我自己被咬過的次數。尤其那條「跟哪張卡衝突」——每一次漏掉,代價都是整輪測試重來。

換句話說,這張表上的每一條,幾乎都是某一次「我早知道就好了」留下來的疤。

我覺得這是規格該有的樣子。憑想像寫出來的需求清單,通常會漏掉最重要的那幾條——因為最重要的那幾條,是痛出來的,不是想出來的。

至於 RD 那一組,我要誠實一點:那三題沒有人來跟我要過。

它是我假設「如果我是 RD,我會需要知道什麼」寫出來的。

我知道這聽起來很弱——規格最怕的就是「我猜使用者需要」。但我有一個間接的證據,而且我覺得它比訪談還可靠:

RD 現在就已經把這些東西寫進票卡裡了。

影響範圍、要小心哪些段落、修法建議——這些內容沒有人規定要寫,但它們就是會出現在卡片的內文和留言裡。昨天那張 32 則留言的卡,整串留言幾乎都是這三件事。

沒有人會花時間去寫沒有人需要的東西。

所以我不是問出來的,是看出來的:他們的書寫行為本身就是需求的證據。這一組如果做錯了,我會知道——因為它會跟卡片上現成的內容對不上。

最後補一句實話:這十一題是一開始就一次列完的,寫到今天為止還沒有增加過。

我不打算把它講成「經過好幾輪迭代才收斂」——因為到目前為止沒有。它們一開始就在那裡,原因就是上面那些:痛過的、看過的、被斷層咬過的。

但我也不保證它不會變。

接下來這 25 天,很可能會出現某個我現在還想不到的問題,而它沒有被這張表接住。真的發生的話,我會在那一天寫出來——包括我漏掉的是哪一條、以及為什麼當初沒想到。

一張在第三天就宣布「完成」的規格,本來就該被懷疑。

真正的考驗也不在這張表列得夠不夠多,而在它有沒有辦法被回答。

那才是接下來 25 天的事。

明天

明天講第一版:一個連 AI 都沒有的靜態網頁。

沒錯,這個系列走到第四天,做出來的東西還是純 HTML。原因我明天講——簡單說是:在讓知識可以被問之前,它得先有地方待著。